The File Delivery Over Unidirectional Transport (FLUTE) implements the file transport mechanism defined in Internet Engineering Task Force proposed standard Request for Comments (RFC) 3926 entitled “FLUTE—File Delivery over Unidirectional Transport,” published October 2004, available at http://tools.ietf.org/html/rfc3926. As currently defined a FLUTE receiver only passes up complete files (i.e., files that do not begin with missing/corrupted data portions or file that do not have intermediate missing/corrupted data portions). Current FLUTE receivers/handlers/interfaces are not capable of discerning whether a partially received file fragment may be useful to a specific application and/or a specific client implementing all or part of that application, such as a Dynamic Adaptive Streaming Over Hypertext Transfer Protocol (DASH) client that may access the DASH formatted files delivered via FLUTE to play back media in such FLUTE delivered files. Currently, a FLUTE receiver is not enabled to parse files; a FLUTE receiver merely delivers files to applications and/or clients.
An application and/or a client providing inputs to a codec, such as a DASH client, may be enabled under certain conditions to recover and provide some portion of a file to the codec even though the file may not have been received by the application and/or client in its entirety. Because FLUTE receivers as currently defined cannot pass incomplete files up to an application, the functionality of applications and/or clients providing inputs to a codec which may be enabled to recover and playback partially received files may be reduced by the current limitations of a FLUTE interface serving those applications and/or clients. As an example, currently FLUTE receivers will simply discard incomplete and/or corrupted files received in broadcast and/or unicast communications, and the discarding of the incomplete and/or corrupted files may result in a DASH player receiving too few symbols for effective Forward Error Correction (FEC) to decode. As another example, discarding of incomplete and/or corrupted files by current FLUTE interfaces may result in a DASH player failing to receive enough data from a Transmission Control Protocol (TCP)/Internet Protocol (IP) connection before playback time. As a further example, discarding of incomplete and/or corrupted files by current FLUTE interfaces may result in a DASH player having a long gap, or long stall, in presenting media content because of lost content.
Incomplete file issues impact more than merely FLUTE interfaces. In the current Hypertext Transfer Protocol (HTTP) 1.1 defined in Internet Engineering Task Force proposed standard Request for Comments (RFC) 2616 entitled “Hypertext Transfer Protocol—HTTP/1.1” published June 1999, available at http://tools.ietf.org/html/rfc2616, there is no mechanism for servers to pass known incomplete versions of files (i.e., files that being with missing/corrupted data portions or files that have missing/corrupted data portions) to clients in response to file requests. In the current HTTP when a server receives a request for a file, or a partial file in the form of one or more byte ranges, such as a “GET” or “partial GET” method, and the server identifies the requested file or partial file is incomplete and/or corrupted, the server merely returns a message with an error status code, such as a message with a 404 “Not Found” status code. In the current HTTP, the incomplete and/or corrupted file is not sent to the requesting client. Because HTTP as currently defined cannot pass incomplete files to a client, the functionality of clients and/or applications enabled to recover and use partially received files may be reduced by current HTTP servers providing files to those clients and/or applications.